2.3 Developing Composite Applications: Application Assembly

Notes/Domino 8 Forum

Subject:

2.3 Developing Composite Applications: Application Assembly - Part 2

Designing Composite Applications: Composite Application Assembly - Part 2
Jo Grant, Craig Wolpert

Prerequisites:
Review Chapter 1 from Composite Applications Toolkit User’s Guide.
Review the Composite Applications Tutorial.

Intro
This is the second article of a two part series covering aspects of application assembly. In the first one we discussed what choices a application assembler has in laying out pages and how to navigate between them to improve productivity. In this one we consider Designing For Change, Wiring Strategies, and how to Prototype Layout because we all know requirements change. It will be common to add or remove components and these changes can be easy to incorproate when using the techniques described below.

Designing for change
One of the advantages of Composite Applications is that they can be easily modified to suit specific business needs or customized by subject matter experts to fit into their work process. Certain design methods can help ensure that applications you design are easy to change and adapt well to growth. Here are some suggestions for making things easy to grow and change.
Wide horizontal folders. We've discussed above how the ability to "stack" components into folders is very powerful. We can place as many components as we need into a small piece of screen real estate. With the ability to maximize tabbed components to the full screen, this method of deployment is also forgiving of different component layout styles. From the point of view of adapting to change it is very easy to add or remove components from tabbed folders without changing the user experience very much. More changes can be made with less user retraining.
Thin vertical columns. This arrangement is not as forgiving of components of varying size. If you can develop a standard size for narrow-column components then this can be an effective way to make space for new components to be added at later dates. Vertical columns cannot selectively show single components like horizontal folders and are best suited for component additions that are best visible at all times.
Cross domain components. Being able to integrate components from different information domains is the greatest hallmark of composite applications. With careful planning and design this is trivial and easy to do. Merging independent efforts or integrating with purchased components will present slightly more challenge. One easy mistake to make is to include additional components just "because they are there". A multi-time-zone clock is a very cool widget, but if it isn't core to your user's work then there is no point in cluttering the UI with it. Another fairly common problem can arise when different types or namespaces are used. This can stop you from being able to wire properties from one set to actions of another set. Use the type and namespace identifiers to protect your application assemblers from making connections that have no sense, and consider developing standards to support the development process going forward. Sometimes, the data can be made available in a variety of types to allow flexibility downstream. Another approach is to create a "converter component". This is simply a component that consumes an action of one type, and produces a property of another type. It can be a purely nominal conversion of type (say from eMailAddress to SametimeID) that leaves the data the same, or a more involved conversion that does some type of lookup (say from EmployeeID to eMailAddress).

Wiring Strategies
Simply placing components on the work surface does not complete a composite application, They need to be wired together. There are usually several ways to wire components together. Some make sense, some do not. Frequently there will be a good design pattern that makes sense for your application. Here are some examples.
As-needed. This is the most general pattern for wiring. Each time you add a component, you wire it into the needed information source. For pages with small numbers of components this is all the structure you need. When there are few components, properties and actions then anything you can wire probably makes sense. As your applications get larger with more components, pages and wires, problems may creep in. Many actions have cascading effects and cause additional properties to be fired. Some properties only fire when the value changes, others when the input changes. It's possible to set up infinite or recursive loops. In general with as-needed wiring, make as few wires as you can in order to make the application work. This leads to fewer problems down the line as the number of components, pages and wires increase.
Inside-out. In a typical layout where you have a few domain centric components and several peripheral contextual domain components there is often a pattern of wiring that radiates from the central components to the periphery. Context changes due to page switching with a cross page wire or selection change take place in the central components. As they are initialized they activate the properties containing the values of the information set they represent. These properties are then wired to peripheral components which use them as the index to the data they show. Occasionally a third tier occurs where the data surfaced by one peripheral component is used by another. But, in general, the data flow is from the inside to the outside which is easier for the assembler to wire and the end-user to understand.
Context preservation. In an application that maintains a complex context, using a cross page wire to communicate a single value to a new page is insufficient to establish the full context. An aggregation component is used in these cases as discussed in Designing Composite Applications: Composite Application Design Patterns. However, in order to preserve context across pages that context must be established in a place that is accessible to various components. Rather than wiring the property from the broadcasting component directly to the consuming action on a display component, wire the property to the action for that value on the aggregation component, and then the property corresponding to it to the action on the display component. This allows the context to be preserved while allowing the component to be involved in all data transactions.
For example: A The Lead Manager CompanyBrowser component broadcasts a CompanyID property that you want to wire to a CompanyDetail component's showCompany action. You could wire the CompanyID property to a setSelectedCompany action on the aggregation component. The showCompany action on the CompanyDetail component would then get the getSelectedCompany property from the aggregation component .
So by using the aggregation component as a "clearing house" for all data exchanges in your application it is guaranteed to have the most recent context for all of the values it tracks.

Prototyping Layout
One of the most exciting benefits of composite applications is that your developers can concentrate on developing components, while the subject matter experts can build applications from those components tailored to meet their needs. As with all application development, the subject matter experts need to be able to communicate their needs to the technical component developers.
Another benefit is that components developed by one group for one application can be used by other groups in their applications. In order to create the most flexible components, the original applications may need to be modified. This can be an arduous and sometimes contentious effort in organizations.
Generally a prototype or strawman is used to convey the changes and the effort required to make the changes. The underlying workflow or process improvements may not be readily visible in a traditional slide-show based presentation. A model of the application showing some of the clickable actions or placeholders for additional features may help communicate both the need for change and the benefits to everyone involved.
As part of the Lead Manager sample, we created a "Mockup Component". This is an Eclipse component that presents a variety of user interfaces based on settings made to the advanced properties. In the screen shot below you can see a mocked up version of the first page of the Lead Manager sample. All of the UI present has been simulated via multiple instances of the Mockup component. It is not functional. Clicking on the buttons presented or making selections in the lists does not have any affect on what is displayed. The purpose is to convey a feeling for what the finished application will be like. Usage scenarios can be explored and, hopefully, design issues surfaced early in the process.

The Mockup component here is capable of eight display modes:

List - The primary area contains a list of items. This can emulate a view or other table driven component
Combo - The primary area has a drop down box of items. This can emulate various selection controls
Button - The primary area contains a horizontal button bar
VButton - The primary area contains a vertical button bar
Info - The primary area contains a list of labeled values. This can emulate a form in read-only mode
Edit - The primary area contains a list of labeled fields. This can emulate a form in read-write mode
Browser - The primary area contains a browser component set to a specific URL This can emulate a component linking to an internal web app. Or, if pointed at a static image, can be used to display a grahical representation of a more complicated component
Blank - The primary area is empty. This can be used to tweak layout

In addition to what is displayed in the primary area, the name that appears on the tab for the component can be manipulated, an optional title displayed in large font on the top of the component, and a list of "action buttons" that appears as a horizontal bar along the bottom of the component.
This is presented as an example of how you can mock up the Lead Manager and other work. You can create your own mockup components that incorporate other common UI themes that are useful in describing composite applications you are designing.

Conclusion
Creating a composite application which increases productivity is the primary goal, but we all know that applications are not static and must always adapt to business changes. It is unacceptable to redesign the application every time new components are added. In this article we added to the discussion of page layouts with suggestions on how to incorporate the ability for future change into your designs. We talked about strategies for maintaining consistent wiring on the pages of your application. And we finished up with a simple component for quickly mocking up UI designs for review.

Feedback response number JGRT77URJM created by ~August Umtumitherader on 10/10/2007